home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 2⁄23⁄90 / 0727-Persistent Observati-Feb90 < prev    next >
Encoding:
Text File  |  1990-02-23  |  2.9 KB  |  74 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  BURBECK.S    to EYES
  2.  
  3. Item forwarded  by  A33          to A34
  4.  
  5. Item    0303279                         20-Feb-90        13:40PST
  6.  
  7. From:   ALGER                           Alger, Jeff,VCA
  8.  
  9. To:     MACAPP.TECH$                    MacApp Technical
  10.  
  11. Sub:    Persistent Observations
  12.  
  13. Persistent Folks,
  14.  
  15. Since the level of discussion of the central issues in object persistence is
  16. quite good, allow me to attack on the periphery with some disconnected
  17. observations.
  18.  
  19. • Has anyone else noticed how much effort is going into working around the
  20. Memory Manager's horrible degradation as a function of number of handles?  Why
  21. not fix it?  Dehydrated objects SHOULD be a viable solution, but is limited by
  22. the MM.  (Side note: this bottleneck will get MUCH worse with the advent of
  23. virtual memory, so it needs to be fixed for entirely unrelated reasons as
  24. well!)
  25.  
  26. • With all the talk about metadata missing from the compiler, what about
  27. post-processing utilities which will scan the source and build the relevant
  28. metadata resources (or whatever)?  Grubby, but doable in a short timeframe.  It
  29. also can handle default behavior for Fields & etc.
  30.  
  31. • It is easy to step over the line from dealing with simple issues of
  32. persistence and virtual objects into the world of OODBMS.  If you need OODBMS
  33. functionality, buy an OODBMS.  If you can't buy one, invent one and make a lot
  34. of money.  The technology is new but not unexplored.
  35.  
  36. In the meantime, the fundamental distinction which needs to be drawn is this:
  37. persistent objects require only a function f(OID)->object, mapping an object's
  38. persistent identifier to the object itself.  This implies no indexing of the
  39. object store on attributes ("give me all x's such that x.y=z") - that is the
  40. province of a OODBMS.
  41.  
  42. • The concept of "ownership" must be addressed, directly or indirectly, by
  43. every application.  In MacApp, this is usually handled implicitly through
  44. procedural code (the network of Free and New calls.)  The RIGHT solution when
  45. dealing with object networks is to handle ownership explicitly through
  46. declarative constructs in the source code.  For example, one could distinguish
  47. between a casual reference and an ownership relationship a la
  48.  
  49. TFoo = Object (...)
  50.   fBar: TBar; Owned;  { Will be freed when SELF is freed }
  51.   fAnotherBar: TBar;  { Implied is that this is a casual reference }
  52.   ...
  53. End;
  54.  
  55. Don't like extending Object Pascal in this way?  How about leaving some
  56. trailings for a post-processor?
  57.  
  58.   fBar: TBar; {$OWNED}
  59.  
  60. Ownership can deal not only with freeing and creation, but storage and
  61. retrieval as well: when you store yourself, store your owned objects at the
  62. same time; same for reading.  Presumably, the default behavior would handle
  63. routine problems but be overridable to handle the new and unusual situations
  64. from which we all earn our livings.
  65.  
  66. This idea is really no different than any embedded DBMS language for a network
  67. database model.
  68.  
  69. Enough for now.
  70.  
  71. Jeff Alger
  72. KPMG Peat Marwick
  73.  
  74.